@cauemarcondes Didn't you recently add this? I suppose we added it for a reason - maybe we were seeing duplicate requests?

I'm wondering if we can keep the caching and solve it by improved cache invalidation. Afair calling refetch should override the existing cache - if not that's probably a bug.

@cauemarcondes Didn't you recently add this?

@sqren No, actually you added it when you refactored the custom link components. But I don't think removing it would be a problem, we already lazy-loading the API call (it's only called when the Action menu is opened). WDYT?

Great, alzheimer's coming early 😴
Okay, removing it sgtm 👍

refetch is working as expected, the issue here is with the callApmApi result being cached. It is invoked each time refetch is called, but with isCachable: true it returns immediately. There are 2 levels of caching here, calling refetch invalidates the first level, and setting isCachable: false disables the 2nd level.

Outside the scope of this PR but shouldn't refetch always circumvent the cache?

... thinking about this some more, it might be hard to handle automatically. We could pass a boolean to the handler that indicated whether the data we refetched:

  const { data = DEFAULT_DATA, status } = useFetcher(
    (callApmApi, refetched) =>
      callApmApi({ 
        isCachable: !refetched,
        endpoint: `GET /api/apm/foo`
      }),
    []
  );

But not sure how i feel about that...